home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 5 / CU Amiga Magazine's Super CD-ROM 05 (1996)(EMAP Images)(GB)(Track 1 of 2)[!][issue 1996-12].iso / cucd / programming / aros / dev / readme.mp < prev    next >
Encoding:
Text File  |  1996-09-12  |  2.9 KB  |  71 lines
  1. WHAT IS IT
  2. ----------
  3.  
  4. Memory Protection (or short MP) means that you want to protect vital
  5. system structures against hostile programs or bugs.
  6.  
  7. HOW AROS DOES IT
  8. ----------------
  9.  
  10. AROS uses several different strategies to implement MP depending on the
  11. overhead for the resource. If you want more speed, you can disable this
  12. schemes altogether. AROS will then run without MP.
  13.  
  14. For compatibility reasons, memory allocated with AllocMem() or similar
  15. (with or without the MEMF_PUBLIC flag) the memory may be read by and
  16. written to by every task. If you want memory which other tasks can read
  17. but must not write to, use the new MEMF_SHARED_READ (Tip: if you have put
  18. some effort in making your code use the MEMF_PUBLIC flag for this kind
  19. of memory, just #undef MEMF_PUBLIC and define it anew as MEMF_SHARED).
  20.  
  21. The new AROS flag MEMF_PRIVATE makes memory inacessible for other tasks.
  22. NOTE: Memory which is currently not allocated by anyone, is protected
  23. like MEMF_PRIVATE.
  24.  
  25. OTHER WAYS
  26. ----------
  27.  
  28. AROS has two more ways to protect your memory. You can change the
  29. protection for memory allocated by you with
  30.  
  31.     MP_SetProtection (APTR memory, ULONG size, ULONG protection);
  32.  
  33. The protection might be
  34.  
  35.     MPPF_NONE - This is the default if you didn't specify MEMF_SHARED nor
  36.         MEMF_PRIVATE
  37.     MPPF_SHARED_READ - Other tasks must not write to this memory but may
  38.         read it
  39.     MPPF_PRIVATE - Other tasks may neither read nor write to this memory.
  40.  
  41. NOTE: If you call libraries, they may access your memory like you (because
  42. they can be thought of sub-functions) but there are some cases where a
  43. library doesn't do the work themself. A good example is PutMsg() and
  44. ReplyMsg(). This is how messages work on the AmigaOS:
  45.  
  46.     1. You create a MsgPort
  47.     2. You allocate memory for a message
  48.     3. You fill the message with some useful contents
  49.     4. You specify the MsgPort as the ReplyPort in the message
  50.     5. You send the message to some other task via PutMsg()
  51.     6. The other task reads and/or modifies the message !!!
  52.     7. The other task replies the message via ReplyMsg()
  53.     8. You get a signal that the message came back
  54.     9. You free the message
  55.     10. You delete the MsgPort
  56.  
  57. Important are the steps 1, 2, 5, 6, and 7. Since ReplyMsg() always
  58. needs to write to your MsgPort, you must allocate it either with
  59. MEMF_PUBLIC or with the call to CreateMsgPort() (recommended since it will
  60. work on future versions of the OS, too). The same applies to the message since
  61. ReplyMsg() must remove the message from the MsgPort you sent it to and
  62. attach it to your MsgPort. So it does NOT matter if the other task
  63. needs only read the message. A message *must* *always* be allocated with
  64. MEMF_PUBLIC.
  65.  
  66. If you need additional protection, for example if you are debugging the code,
  67. you can use MP_SetProtection() to protect specific parts of the message,
  68. but you should not use this function in the final version of your application
  69. since it uses *lots* of ressources.
  70.  
  71.